Session Initiation Protocol (SIP), defined in Request for Comments (RFC) 3261, is an application-layer control and signaling protocol for establishing, modifying, and terminating real-time calls and conferences over primarily Internet protocol (IP) networks. A SIP network typically comprises numerous elements, including SIP user agent servers (UAS), SIP user agent clients (UAC), proxy servers, redirect servers and registrar servers.
SIP defines a layered communications protocol model as outlined in FIG. 1 which shows a typical SIP stack 100. The stack comprises a network layer 102, a transport layer 104, a transaction layer 106, an optional dialog layer 108 and a service or application layer 110.
The network layer 102 provides the appropriate Internet protocol (IP) connectivity to enable each SIP element to communicate over an IP network.
The transport layer 104 defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. A SIP server is a network element that receives requests in order to service them and sends back responses to those requests. The transport layer 104 is also responsible for framing SIP messages over the network.
The next layer is the transaction layer 106. A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer is responsible for enforcing compliant message sequences and for retransmitting and filtering duplicate SIP messages if the transport layer is not reliable. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions.
The layer above the transaction layer is the transaction user (TU), or service layer 110. The service layer 110 is the application running on top of the SIP stack which provides the element specific functionality.
An optional dialog layer 108 may exist between the service layer 110 and the transaction layer 106. A SIP dialog identifies a set of related transactions. For example, in a standard phone call, setup and tear down are two related transactions within a single SIP dialog. The dialog layer is responsible for enforcing compliant transaction sequences and for managing the deficiencies between them.
SIP elements send requests and responses to other SIP elements in the form of SIP messages. SIP messages contain extensive information containing details, for example, of source address or URI, destination address, routing details, call identifiers, sequence numbers and so on as will be appreciated by those skilled in the art.
The SIP message format allows significant flexibility in the way in which the header information may be arranged and ordered within a message, and situations can arise where messages are logically equivalent whilst being syntactically different. For instance, SIP does not specify, for many headers, the order in which they should appear in a SIP message. Furthermore, SIP headers are generally case indifferent and SIP stacks from different vendors may construct messages in different ways. However, it is important that all SIP stacks are compatible with one another.
The decoding of SIP messages is performed by a grammar parser 112 which is an integral component of the SIP stack 100. The grammar parser 112 parses the message and extracts information relevant to a particular layer. Due to the number of different ways in which a SIP message conveying the same information may be constructed the grammar parser has to be able to extract the header information, parameter data and the like, irrespective of the message formatting. For example, the grammar parser has to be able to cope with upper and lower case characters, and variants of header separation such as line-feed characters, spaces, semi-colon, tab characters and so on. Grammar parsers thus provide complex parsing functionality. SIP stacks are typically provided as generic off-the-shelf components, and implement the whole of the SIP specification, making them suitable for use with any kind of SIP element.
Each of the different types of SIP element provide differing degrees of functional complexity, and the quantity of messages processed by each type of element varies widely. For example, SIP user agent clients and user agent servers are capable of performing complex processing and communication tasks, for example when setting up a call. At the same time, though, the number of messages processed by a UAC is typically relatively small. For example, a UAS may typically only process messages in relation to a call establishment request made by the UAC. Once a call is established, it is possible, assuming that no changes are made to the call parameters, for the UAC or the UAS not process any further messages until the call terminates.
Other elements, such as SIP redirect servers, on the other hand, perform somewhat simpler processing tasks, but receive a much higher quantity of messages to process. For example, a SIP redirect server performs the relatively simple task of registering a mapping between a SIP URI and an IP address at which the SIP URI can be reached. This is a fundamental task in a SIP network since redirect servers are used by SIP proxies for obtaining the current IP address of a user device prior to routing a call. This is particularly important in cases where mobile UACs access the network, as typically IP addresses are dynamically allocated and may change frequently. Furthermore, to ensure that the mapping information is up-to-date, each mobile UAC typically sends REGISTER messages at frequent intervals.
It is clear, therefore, that the number of such messages to be processed by a redirect server is typically substantially higher than those processed by a UAC. As an example, current registrar servers can typically process between 200 and 1000 registration operations per second.
However, with the emergence of new services using SIP, such as so-called push-to-talk (PTT) services, is expected a significant increase in the number of certain messages being sent, and this is likely to put strain on the existing network elements charged with processing these messages. It is foreseeable that some such elements may not be able to cope with this increase demand.
For example, push-to-talk services typically require each mobile device on the network to send a REGISTER message at least every five minutes. Not only will this lead to a significant increase in the number of such messages being sent across the network but as the popularity of such services grows so the number of mobile devices connected to the networks is expected to dramatically increase, thereby further compounding the situation.
As previously discussed, all SIP elements have been conventionally based on the same implementation model comprising a generic SIP stack plus an application or service layer providing the element specific functionality. This model has been used largely to ease the development times and cost of SIP network elements and to ensure interoperability with other network elements using SIP stacks from different vendors. However, due to increased performance pressures it is becoming apparent that, for certain SIP elements at least, such an approach is no longer desirable.
Accordingly, one aim of the present invention is to overcome or alleviate at least some of the aforementioned problems.